Immeasurable gains in technology offered in personal computers ("PCs") have allowed PCs to assume roles performed only by mainframe or minicomputers in the past. Many companies and individual users rely solely on commercially-available PCs, such as those provided by NCR, to meet their information processing needs. Thus, it is vital that their PCs perform reliably. If, however, a PC experiences a fault, it is equally vital that the PC communicate existence of the fault to inform the user of a need to repair the fault so the PC can return to active service. For computer systems in general, it is most helpful for the computer system itself to provide an indication of the specific location and nature of the fault to help the user more quickly isolate and more economically repair the fault. To that end, today's PCs are typically equipped with some form of internal diagnostics, the purpose of which is to detect and subsequently isolate specific hardware and software component failures and faults brought about by interactions among the PC's hardware and software components (so-called "conflicts" leading to so-called "configuration faults").
For years, PCs have been provided with diagnostic routines that test and report on the operational status or functionality of hardware and software components within the computer, allowing a user to repair or replace hardware or software components that are not functioning to the desired degree or to resolve certain conflicts manually.
As PC systems become more and more complex and as users come more and more to rely on the services of remote, skilled technicians to maintain and repair their PCs, it is growing less desirable to force the user to diagnose PC faults alone. The general direction in the development of diagnostic software systems to this point has been to isolate the user somewhat from the intricate and technically complex operations of diagnostic routines by: (1) providing more user-friendly diagnostic programs to the user, with interfaces written in clear text and presented in an aesthetically pleasing manner and (2) providing remote diagnostic capability so the remote technician may query the PC directly and determine faults without the user's substantial participation. However, the user is still forced to undergo a fault and contact a remote technician for help.
Unlike outright hardware or software failures, conflicts arise quite frequently and are entirely predictable. Quite often, technicians see the same conflicts over and over again. Users having similar hardware and software configurations tend to experience the same conflicts, some earlier than the rest. Therefore, the user may not have had to experience the conflict in the first place.
The solution to such configuration problems usually involves manually correcting the computer's configuration by revising (usually updating) portions (such as libraries and hardware drivers) of the computer's operating system. The remote technician or the user may effect these revisions. Unfortunately, the above-described solutions to the diagnostic problem still require the user to suffer a fault and contact a technician, even if it is an avoidable fault due to a conflict.
In the past, the answer has seemed to lie merely in automating the diagnostic process. For example, U.S. Pat. No. 5,287,505, issued on Feb. 15, 1994, to Calvert, et al., and entitled "On-line Problem Management of Remote Data Processing Systems, Using Local Problem Determination Procedures and a Centralized Database" is directed to automated problem analysis and resolution of a customer data-processing system in which a central service data-processor system communicates with the customer system. Included is a database for converting machine, software and symptom data into instructions, hardware and software module lists, and service call schedules. The customer system detects data concerning its own configuration and problem symptoms for communication to the service system. The service system itself orders repair modules, and electronically communicates software fixes to the customer system.
Unfortunately, Calvert, et al., is expressly directed to repair of a fault once it has occurred and does not provide a means by which to anticipate and avoid faults, particularly configuration faults arising out of hardware/software conflicts.
In the past, some effort has been given to automating the process of software revision to avoid prospective, purely software-based faults. For example, U.S. Pat. No. 5,155,847, issued on Oct. 13, 1992, to Kirouac, et al., and entitled "Method and Apparatus for Updating Software at Remote Locations" is directed to a method and system for updating the software used in remote computer systems from a central computer system. The method includes storing, in the central computer system, copies of the software executable used in each remote computer system. When the copies of the software in the central computer system are upgraded, for example, to correct the software, to add new facilities, to change user interfaces, to make cosmetic changes, to improve performance, etc., each change made to the software is monitored and stored. The remote computer systems are permitted access to the central computer system via communications links and the software in the remote computer systems and the corresponding software in the central computer system are compared. All of the changes that have been made to the software in the central computer system which have not been made to the corresponding software at the remote computer system accessing the central computer are detected. The detected changes are then transmitted to the remote computer system and applied to the software therein in order to upgrade the software in the remote computer system. The upgraded software in the remote computer system is examined to ensure that the software has been changed correctly. The method allows the software at the remote computer systems to be upgraded even while the software at the remote site is being used. The system and method also allow the software used in the remote computer systems to be upgraded when the remote computer systems use different versions of the software and allow the software to be upgraded in a variety of hardware environments and operating systems.
Unfortunately, Kirouac, et al., is directed only at revising application-level software. Kirouac, et al. is not directed to analyzing the complete hardware and software configuration of a computer system in an effort to identify hardware/software conflicts and potential configuration faults. Further, Kirouac, et al., is not directed to revising components of the computer's operating system.
Given that potential faults due to conflicts are diagnosable and readily repairable, what is needed in the art is a system and method for automatically correcting hardware/software conflicts that have potential for causing a fault, preferably well before they actually become faults. The system and method should be capable of distributing or receiving software revisions that are a function of a specific system hardware and software configuration to address the conflict.